Within the prior art, a well recognized problem in the trouble shooting and monitoring of packet networks that are transmitting multi-media such as voice-over-IP (VoIP) is to trace the route between two network devices and to determine the round-trip-times (RTT) that voice/media packets are experiencing. With respect to determining the route (commonly referred to as traceroute) it is known in the prior art to utilize ICMP or User Diagram Protocol (UDP) packets in traceroute implementations. Since the actual media information is being transported by RTP packets, the prior art use of ICMP packets and UDP packets results in different IP protocol or source and destination ports being utilized between two network devices than the actual ones utilized by the RTP packets. The reason for the use of different UDP source and destination port numbers is so that when the packet eventually gets to the destination it is rejected because the port number is not recognized. In addition, the ICMP packets and UDP packets may not follow the same network path or be given the same Quality of Service (QoS) treatment as the RTP packets for a number of reasons. First, RSVP reservations are utilized to set up the path through a network for the RTP traffic, but the ICMP and UDP packets do not of necessity follow the path setup utilizing the RSVP reservations. Second, it is well known in the prior art that firewalls and gateways may block UDP traffic not considered to be a RTP packet. Third, it is also known within the prior art for firewalls and gateways to discard traffic not of the same size as the expected RTP packets. Fourth, it is also desirable for VoIP devices (particularly high port density devices) not to respond with standard ICMP destination unreachable packets for all UDP traffic and/or ICMP echoes to circumvent DoS attacks. The returned ICMP destination unreachable packets for UDP packets and/or ICMP echoes are necessary to determine the route through the network since these return packets are used to obtain the route information. Because of these four reasons, problems can result in traceroute packets following a different IP route as compared to the route followed by the RTP packets that carry the media. Also because of firewall and gateway filtering, as is well known in the art, a route for the ICMP or UDP packets may not exist at all through the network.
Related problems exist in the determination of the RTT using real time control protocol packets (RTCP). Since RTCP packets are sent using a different UDP source and destination port, it is not unlikely that the RTCP packets will receive a different treatment by the network. An additional requirement on the RTCP packets when used to determine the RTT between network devices, is that the packets must be marked with the same Diffserv code points (DSCP) as the RTP packets in an effect to gain similar treatment from the network as that provided to the RTP packets. However, utilizing the same DSCP for the RTCP packets as that used for the RTP packet does not resolve all problems as follows. First, RTCP packets vary in size and are generally larger than RTP packets which effects their treatment by a network. Second, RTCP packets are sent at a rate as little as 1/500th of the rate that RTP packets are sent which may also effect their treatment by the network. Third, RSVP reservations made to protect RTP streams of packets are unlikely to be made to protect the RTCP stream; and if the RSVP packets were made for the RTCP packets they could fail, and/or be treated differently because of the vastly different traffic profiles. In summary, the results in the RTT calculated by RTCP packets may be different than the actual RTT experienced by RTP packets carrying the actual media.